Using multiple computers to simultaneously run multiple tasks, particularly where the tasks are related or need to interact, requires some communication facility between the multiple computers and tasks. For instance, if one processor wants another processor to handle some task for the first processor (e.g., start an input/output process), or if one processor wants to restart another processor, the first processor can store the communication request in a shared memory and the other processor can then retrieve it. Conversely, the first processor can directly request that the task or action be handled by the other processor. These communications are usually accomplished via a "bus" or signal pathway between the multiple computers.
In a multiprocessing environment, interrupts are one mechanism for interprocessor communication. Other mechanisms include semaphores, queues, tables, or other memory based structures. For instance, memory based operations require processes to regularly poll memory to check for outstanding communications. This polling results in additional bus traffic for many of the memory references. Further, polling uses a system resource to execute the polling thus making the resource unavailable to do real work while the polling is in progress.
Interrupt requests are usually sent directly from one processor or agent to a second processor or agent. If the second processor is busy when the interrupt request is received, either the second processor gets interrupted or the first processor must wait and re-issue the interrupt request at a later time. The problem is, if the second processor is interrupted then the task it was busy running must be halted. Alternatively, if the second processor is too busy to be interrupted (it may be running a particularly high priority task, for instance) then the first processor's requested interrupt won't be handled yet.
Furthermore, regardless of whether or not the second processor was interrupted, there may be a third processor which is either sitting idle, or running a less important task, and which could have handled the interrupt request from the first processor. However, with directed interrupts, the third processor is unable to respond to the interrupt request directed to the second processor. And if the second processor did get interrupted, this may still be inefficient if the third processor was running a task less important than the task which was running on the second processor but which task is now halted.
A further problem arises if it is particularly important to the first processor to have a particular interrupt handled. In order for the first processor to be assured that the particular interrupt will be handled by the processor the interrupt is directed to, the particular interrupt would have to be made a very high priority. In this way, regardless of what the processor the interrupt is directed to is currently running, the processor gets interrupted. Unfortunately, the task the interrupted processor was running may have had a fairly high priority itself. And that task is now halted. Again, if there was another processor available (either because it was sitting idle, or because it was running a lower priority task), then originally sending the interrupt request at a high priority to ensure that it interrupts the processor it is directed to may not be the most efficient method.